[PATCH 1/4] mgr/volumes: Fix subvolume discover during upgrade
Fixes the subvolume discover to use the correct
metadata file after an upgrade from legacy subvolume
to v1. The fix makes sure, it doesn't use the
handcrafted metadata file placed in the subvolume
root of legacy subvolume.
Co-authored-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@cern.ch> Co-authored-by: Dan van der Ster <daniel.vanderster@cern.ch> Co-authored-by: Ramana Raja <rraja@redhat.com> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Gbp-Pq: Name CVE-2022-0670.patch
[PATCH] client: prohibit unprivileged users from setting sgid/suid bits
Prior to fb1b72d, unprivileged users could add mode bits as long as
S_ISUID and S_ISGID were not included in the change.
After fb1b72d, unprivileged users were allowed to modify S_ISUID and
S_ISGID bits only when no other mode bits were changed in the same
operation. This inadvertently permitted unprivileged users to set
S_ISUID and/or S_ISGID bits when they were the sole bits being modified.
This behavior should not be allowed. Unprivileged users should be
prohibited from setting S_ISUID and/or S_ISGID bits under any
circumstances.
This change tightens the permission check to prevent unprivileged
users from setting these privileged bits in all cases.
Joshua Baergen [Wed, 17 May 2023 18:17:09 +0000 (12:17 -0600)]
CVE-2023-43040 rgw: Fix bucket validation against POST policies
It's possible that user could provide a form part as a part of a POST
object upload that uses 'bucket' as a key; in this case, it was
overriding what was being set in the validation env (which is the real
bucket being modified). The result of this is that a user could actually
upload to any bucket accessible by the specified access key by matching
the bucket in the POST policy in said POST form part.
Fix this simply by setting the bucket to the correct value after the
POST form parts are processed, ignoring the form part above if
specified.
Popen.communicate() returns a tuple (stdout, stderr), and stderr
will be of type bytes, hence the need to decode it before checking
if it's an empty string or not.
Gbp-Pq: Name CVE-2022-3650_2_ceph-crash_fix_stderr_handling.patch
If privileges cannot be dropped, log an error and exit. This commit
also catches and logs exceptions when scraping the crash path, without
which ceph-crash would just exit if it encountered an error.
Gbp-Pq: Name CVE-2022-3650_1_ceph-crash_drop_privleges_to_run_as_ceph_user_rather_than_root.patch
see also
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/std_executors.html#boost_asio.std_executors.polymorphic_i_o_executor
we could use `asio::any_io_executor` later on though for better
performance.
also, define CMP0093, so FindBoost reports Boost_VERSION in x.y.z
format. it is simpler to use `VERSION_GREATER_EQUAL` to compare its
version with 1.74 instead of its C macro version ("107000").
Gbp-Pq: Name cmake_define_BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT_for_Boost.Asio_users.patch
Kefu Chai [Fri, 28 Jun 2019 03:35:54 +0000 (11:35 +0800)]
[PATCH] os/bluestore/BlueFS: use uint64_t for `len`
change the type of parameter `len` of `BlueFS::_read_random()` from
`size_t` to `uint64_t`.
i think the type of `size_t` comes from
`rocksdb::RandomAccessFile::Read(uint64_t offset, size_t n,
rocksdb::Slice* result, char* scratch)`. and when we implement this
method, we continued using `n`'s type. but, we are using it with
`std::min()`, for instance, where the template parameter type deduction
fails if the lhs and rhs parameters' types are different. so probaly the
better solution is to use `uint64_t` directly to avoid the the cast and
specializing the template.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Gbp-Pq: Name bluefs-use-uint64_t-for-len.patch
unsigned and size_t are equivalent on 32 bit architectures,
so only define the size_t based overload of advance on 64
bit architectures.
https://wiki.debian.org/ArchitectureSpecificsMemo
Bug-Ubuntu: https://launchpad.net/bugs/1756854
Bug-Ubuntu: https://launchpad.net/bugs/1766998
Forwarded: no
Last-Update: 2018-04-24
Instead of -source/-target ceph should be build with --release for OpenJDK 9
or later so that the bootclasspath is also set, as per JEP-247, otherwise it
risks incurring into binary incompatibility when run with an earlier OpenJDK.
OpenJDK 11 minimum compatibility release has been updated to 7.
Last-Update: 2018-04-24
Gbp-Pq: Name update-java-source-target-flags.patch
* Non-maintainer upload by the LTS team.
* Add patch to check if HTTP_X_AMZ_COPY_SOURCE header is empty.
(Fixes: CVE-2024-47866) (Closes: #1120797)
* Add patch to fix subvolume discover during upgrade.
(Fixes: CVE-2022-0670) (Closes: #1016069)
projects / ceph.git / log